Amiga Collections: Taifun/Taifun 136 (1990-05-15)(Ossowski, Stefan)(DE)(PD).zip/Taifun 136 (1990-05-15)(Ossowski, Stefan)(DE)(PD).adf/ScreenZap/ScreenZap.Docs

Text File | 1990-02-23 | 8KB | 157 lines

                    About ScreenZap Version 2.3

                                or

               How to survive when your screen goes awry...



   WARNING:

   As this program kills things without asking permission from  anybody,  it
should  only  be  used  when  there  is nothing to lose.  Get your pictures,
source codes, texts, databases, money and who knows what else  saved  before
you try anything like this. When there is nothing to lose, go ahead. Most of
the  time,  it cleans up nicely, avoiding a reboot for some time. But do not
be surprised when it goes GURU, as a system with screens and windows on  the
loose is unstable in itself.


   Short History:

   ScreenZap is possibly the most guru-aktive program  that  works.  It  was
cooked  up  a  year  ago,  when  my  memory  became filled with screens from
programs I had ^C'ed out of. As I didn't want to reboot too  often,  and  no
other  program  I'd  heard  of could help me, I made a simple hack to kill a
screen.  Later it was cleaned up, made to take single windows  and  multiple
screens,  and  began  using CloseWindowSafely, and now this version is about
the safest code of this type I can make.


   How ScreenZap Works (when it does:-)

   ScreenZap is made to  kill  screens  and  windows  left  over  by  ^C'ed,
debugged  or  otherwise dead programs.  When killing, it Forbid()s away from
the multitasking system to avoid an even messier death. Then it looks in the
IntutionBase to find otherwise disappeared screens/windows, and  kills  them
off  in  the  correct  order  (buttom-up),   using   CloseWindowSafely   and
CloseScreen. It will never try to close the WorkBench.


   How To Use ScreenZap:

   When a screen/window goes undead, i.e. only Intuition knows about it,  it
is  a  very  dangerous thing. As they may not have all the memory they think
they have, the killing should be handled with care. When you  have  such  an
undead  screen/window, try to touch as little as possible.  Get WorkBench up
front with LeftAmiga-N and work  from  there.   If  the  window  is  on  the
WorkBench screen, ScreenZap should be to-backed just before you try and kill
the window.
   If there are other screens you'd like to keep, as they  may  still  live,
either  get those in front of the WorkBench and kill only those left behind,
or get the undeads in front and kill them one at a time.
   Use the method that involves the least touching, as  even  an  activation
may cause a crash.
   To run ScreenZap, either doubleclick its icon or call it from CLI with:

   1 DH0:-> ScreenZap

   ScreenZap takes no arguments whatsoever.

   A window will now appear with 4 gadgets. The first three of them are  for
zapping  screens, the last for windows.
   "Kill  Screens Behind WorkBench" will try to remove all the screens lying
behind the WorkBench,  also  the  MandelVroom  you  were  running  at  lower
priority  while  working,  which  will bomb you out from under your bed.  So
again, know just what you shoot.
   "Kill Screens Except WorkBench" does the same, but also on the screens in
front of WorkBench.
   "Kill Front Screen" will kill only one screen, the one in front,  and  it
will  not  try to close WorkBenchScreen. This is the safest of the three, as
you can see what you close. After zapping screens, the title bar  will  show
how  many  screens and window were removed. ScreenZap will then be ready for
yet another zapping.
   "Kill Front Window On  Front  Screen"  will  close  the  foremost  window
regardless  of  what's  going  on  in  it.   If  the  window to be closed is
ScreenZap's own, it will ask for confirmation. If you  then  press  anything
but  the  closegadget,  it  lives  on.   Otherwise, it closes peacefully.  A
SuperBitMap will NOT be deallocated, as others may still be  using  it.   In
the  case  of  a shared messageport, ScreenZap now uses CloseWindowSafely to
avoid an unpleasent meeting with a guy from India.

   Now click on the appropriate gadget and watch either the undead  go  away
or  the  machine go very dead. You may, of course, kill as many times as you
dare and got undeads to kill.   After  this  bloody  mess,  exit  gracefully
through the CloseGadget, and pray there isn't a ticking bomb in the system.
   You may sometimes want to kill  a  screen/window  whose  maker  is  still
alive,  but  for example caught in a never ending loop, waiting for anything
BUT a window report. This will be done as readily as any other screens,  but
be  ABSOLUTELY  sure  the  program  will  never  again even try to touch the
window, or you will experience the FIREWORKS_DISPLAY mode! It would be better
to use a program like AbortCommand to stop the program first.


   Some Typical Ways To Die Are:

   If a window or screen is zapped, and a program tries to use it,  it  will
find  garbage  instead of pointers, and try to use it. It is probably one of
the simplest ways of making a total system crash, it seldom even GURU'es.  I
tried  avoiding  this  in  the  start  by  sending  the window in question a
CLOSEWINDOW message, but as it created more poblems  than  it  solved,  I've
removed  it. It is now up to the user to ENSURE that no program will try and
access it.
   Having a window/screen whose titletext has changed, the program  suddenly
stops  without  closing  it.   The  Title  now lies somewhere in newly freed
memory, and other programs may get that. I've even seen one  of  ScreenZap's
gadget texts in an undead window I was careless enough to  activate  (boom).
You  can  typically  see this if ScreenZap's own title disappears or becomes
garbage.
   SuperBitMaps poses a problem, as they fill up memory without being closed
by CloseWindowSafely.  This may be the only thing I will  add  to  ScreenZap
later on.
   Shared IDCMP ports should be closed safely with CloseWindowSafely(),  but
in  this  state, noone knows. I can't even debug it, as the Forbid() clashes
horribly with the debugger.
   Sometimes, it seems,  a  window  will  just  disappear  from  Intuition's
knowledge  without  erasing  the display. Trying to kill such a ghost window
will propably go back and hit ScreenZap, who in turn will ask if  it  really
must  close. In this case, don't close, go on to killing the screen, and you
might still survive.


   Recompiling:

   Recompiling ScreenZap is easy, just

   1> cc ScreenZap
   1> ln ScreenZap.o c.lib

   It compiles easily under Manx V3.6, I know not whither Lattice can manage
it, but it should. And it does (comes Big Brother in).


   Disclaimer, Notes And All That Stuff:

   I am in no way  responsible  for  any  damage  done  to  your  system  by
ScreenZap.   This  is  the  final warning: If you think it is too dangerous,
reboot. It's better to wait a minute for a fresh boot than  a  month  for  a
fresh Amiga.
   You may distribute this program as you want, as long as
      1) All the parts (ScreenZap, ScreenZap.c ScreenZap.doc & icons) are
         distributed together.
      2) I stand as the author of the program.
      3) You don't take any money for the program itself. Inclusion in PD
        collections is OK, as are electronic transfers.
   Hack up the code to use in your own programs if you want to, but  if  you
make any bugfixes/improvements, I'd like to hear about it.
   I would be very interested if anyone made a better version,  for  example
one that could kill tasks also (Kill on Fish 79 didn't work.)
   If you really use this program much, send response, other  programs,  $$$
or Amiga2500UX'es to
                                       Lars R. Clausen
                                       Hougårdsvej 29
                                       8220 Brabrand
                                       Denmark
                                       FidoNet: 2:234/22.34